《全程软件测试(第3版）》读书笔记

【引子】

2019年初的时候测试Cop的小伙伴们说我们今年一起搞个拆书活动吧。于是，我推荐大家把朱少民老师的《全程软件测试》一起来拆书学习。

2019年很忙，项目不停的迭代，各种测试版本、商用版本冲刺发布，一度觉得都要完不成拆书任务了。不过，最终还是在12月份把书拆完了。今天简单总结一下个人的读书笔记心得。

【开胃】

读书笔记开始前先抓几个书中印刷小Bug^_^不知道各位读书的时候有没有发现？作为一个测试，找Bug就是一种本能乐趣~

【过程杂记】

第1章 360度看软件测试：一览无余

感悟思考：

1. 书中基于风险的认知部分二八原则的说法并不严谨，实际还是要看项目背景的。

2. 书中说：如果TestOracle属于启发式的，需要综合判断的，就需要手工测试。

==这里手工测试描述并不妥当，应该为人工测试更合适一些。

（编者注：20/80原则是一般性或理想情况下的原则，具体case会有一些差异；自动化测试也可以说“人工测试”，手工艺者主要靠双手做产品，手工测试更强调靠测试人员双手完成测试。）

第2章 全程测试：闪光的思想

感悟思考：

无~ 

（编者注：思想更需要感悟，不能“无”啊😄）

第3章 准备：基础设施与TA框架

摘抄：

基础设施的两个优秀实践：

• 一切都是API

• 基础设施即代码（Infrastructure as Code, IaC）

IaC要实现标准化、高度的自动化和可视化等目标，必须遵循如下一些基本原则：

• 复用性。环境中的任何元素都可以轻松复制，在其他场景中使用。

• 一致性。无论何时，创建的环境各个元素的配置是完全相同的。

• 快速反馈。能够频繁、容易地进行变更，并快速知道变更是否正确。

• 可视性。所有对环境的变更易理解、可审视、受版本控制。

感悟思考：

这部分内容（3.2章节）值得反复深入理解，目前xTest（我们测试小伙伴自己搭的测试提效工具）也是按照两个优秀实践指导开发的，但是基本原则细节方面有待打磨提升。

第4章 准备：个人与团队

感悟思考：

个人能力模型可以仔细研究图4-4，给了测试人员自我提升的一个方向指引，我个人更关注4个层面的能力：

1. 测试能力：最最基本的测试分析、设计、建模等能力

2. 业务知识：产品业务背景知识等

3. 软件知识：计算机原理、通信原理、代码等

4. 测试思维：批判性思维、系统思维等

团队建设方面书上写的比较少，不过瘾

第5章 项目启动：知己知彼、百战不殆

感悟思考：

项目启动这一章节其实就是讲如何进行信息搜集，个人读后感觉仅仅是点到为止，没有经历过真实大项目的人是很难有深入的感悟的。

第6章 测试计划：分析与策略

感悟思考：

风险管理部分值得细细品味，图6-10还需进一步学习解读

第7章 测试设计：架构与用例

感悟思考：

Checklist确实是个好东西。

设计总想完美、覆盖全，但是真要让人去测试就往往痛苦不堪了，有些测试点如果不用考虑执行成本，往往也就不会在评审的时候测试说要测，开发说不要测了。一切都是基于风险、成本的考虑。

第8章 测试执行：自动与探索

感悟思考：

Bug Bash如果时间短，一般很难深入。Bug Bash除了故障，我更看中的是大家一起学习交流探讨，思维的碰撞。

不太好的是，自己现在所在项目目前只安排做过一次。应该多做的。

第9章 永不收尾：持续反馈与改进

感悟思考：

不断复盘、不断改进。

不要以为版本测试发布了就算结束了，这仅仅是完成公司设置的一个里程碑而已。实际我们的产品质量怎样？需要不断通过测试去反馈、去改进。

第10章 全程静态测试：以不变应万变

摘抄：

评审的目标是尽可能发现存在的缺陷和问题，会议应该围绕着这个中心进行，而不应该陷入无休止的讨论之中。评审也不能偏离中心，将话题转到该问题的解决方案上，因为评审会议的目的是发现问题而不是解决问题。

==很喜欢这段话

对于需求的说明，不能含糊，不能引起二义性，这样才能最大限度地保证每个人在阅读需求文档时不会产生不同的理解。例如，需求定义中不应该使用不确定性的词，如“有时、多数情况下、可能、差不多、容易、迅速”等，而应明确指出事件发生或结果出现所依赖的特定条件。

==摘抄一下，供参与需求评审的测试同学学习

需求评审的质量要求：正确性、完备性、易理解性、一致性、可行性、易修改性、可测试性、可追溯性

==可以考虑做个检查单（checklist），供大家学习

我们这里特定要说明一下需求的可测试性，这在敏捷开发中显得更为重要，敏捷开发对文档不够重视，在文档上投入就会少，需求描述过于简洁，文档质量堪忧。

==对这句话持不同意见。这是国内敏捷的一种现状，但不是敏捷的问题。

（编者注：主要是指不少团队做敏捷开发，只写用户故事，而不同时完成验收标准，即没有推ATDD，从作者看，ATDD在敏捷开发中是必须的，因为仅仅是用户故事是不可测的）

感悟思考：

设计的可测试性往往被忽略，以前在业务网元项目的时候特别重视这个，甚至在方案中都会明确日志该如何打印、调试打印函数该如何设计。目前项目这块有点欠缺。

第11章 全程性能测试：持续优化

摘抄：

优秀的性能测试工程师：从项目启动时就关注性能、准确来说，就关注性能需求是否明确、合理、可测，然后关注系统架构的设计，在设计中是否很好地考虑了性能需求。在性能测试之后，还关注性能的调优，产品上线后还进一步监控系统性能的实际表现。这还没有结束，根据开发性能调优之后或产品上线后还进一步监控系统性能的实际表现。这还没有结束，根据开发性能调优之后或产品上线后的日志分析，再开始一个新的循环。他们始终认为性能就是在不断测试、分析、调优、监控的过程中，持续优化的过程。

感悟思考：

性能是系统工程，勉励，持续提升。

第12章：全程安全性：持续加固

摘抄：

微软SDL在整个软件风险生命周期定义了7个接触点：滥用案例、安全需求、体系结构风险分析、基于风险的安全测试、代码评审、渗透测试和安全运维。

感悟思考：

我们项目在威胁建模、安全需求、渗透测试方面需要不断探索深入。

第13章：全程建模：彻底自动化

感悟思考：

MBT是个很好的愿景，业界也有很多优秀实践，但是一直没有大规模铺开。

模型抽象能力其实对人是有一定要求的，很遗憾，我们很多测试人员这方面的技能太差。想要用好MBT对于人的能力、工具的支持是两块大的难点和门槛。

第14章 全程可视化：管理无死角

感悟思考：

全过程的度量，看完之后是不是有些懵？

这一章节要是能有一些战略取舍的案例就更好了，全都做是有代价的，真实项目永远是在做价值评估，进行相应的取舍。

（编者注：留给读者取舍，第4版可以标注哪些必选项、哪些是可选项）

第15章 测试展望：未来更具挑战

摘抄：

对于AI软件的测试，实际有一个时间维度，AI软件随着时间能够不断学习（人工智能中最重要的分支是机器学习），其能力必须（快速）增强，说明和人类一样，能力是不断成长的，这才是一款真正的AI软件。

AI软件的测试，更多的是靠“试验”进行验证，这和“Test”倒是更吻合。

感悟思考：

如何测试AI软件，比较难，业界也没有很好的实践，但是已经有一部分人正在不断探索。如何利用AI辅助测试，是一个很好的方向，这块可以做一些了解储备。

【书评总结】

1、本书的第1章值得从事测试的各位同学多翻阅几遍，一定要对测试有一个正确的认知，通过不同的角度去思考，你才能看得更系统更全面，建议大家反复多读多悟。

2、个人在第3章和第10章上面看的相对更细致一些，主要在项目实践中有痛点：

软件测试的基础设施相当重要，对于基础设施的优秀实践总结非常认同，自己项目也是按照书中说的原则进行实践。但是第3章对于测试环境的管理维护上面讨论不多，看的有些不过瘾。因为我从事的都是系统产品相关的测试，对于测试环境的管理一直是工作中的一个重要的环节。如何更合理的规划好测试组网环境，如果更高效的利用好资源在真实项目中很重要。

第10章是老生常谈的话题，都知道需求重要、方案重要，但是实际项目运作时，我们又总是在实际行动上证明我们并没有真正在乎需求的质量、在乎方案的质量，总是在挤压需求讨论、方案设计的时间。在需求分析、方案设计层面的研究上大家并没有花太多的精力去研究。BDD/DDD/ATDD这些优秀的实践，有多少人去认真研究，真正的去在项目上推进落地？测试的同学永远要记住需求的重要性，当需求都是有问题的时候，测试发现再多实现层面的细节问题又有何用？

3、第11、12章对于性能、安全这两个专项的章节，主要建立的是一个宏观层面的认知，要想深入掌握理解，还需测试的同学不断深入学习总结。两个都是系统性的工程。值得我们测试不断去深入探索。尤其对于安全，这两年明显感受到整个行业对于这一领域的关注度在不断提升，这是一个很好的值得探索的方向。

4、第15章是对于测试的一些展望，AI绝对是一个重要的方向，大家不要以为AI离测试还很远，实际AI已经在测试领域有不少实践应用。譬如安全测试领域，就有不少成功的实践。测试需要保持学习，新东西，多了解多看一些总是不坏的。

5、测试还有很多值得我们去探索的，新兴的云计算、物联网、大数据等技术方面我们测试该如何探索值得研究探索，而软件安全和软件可靠性这两个专题实际也是相当重要的一个分支，当软件越来越普及的今天，可靠性和安全绝对是越来越重要，值得我们去研究思考。期待后续的第四版、第五版在这些方面有进一步的分享。

全程测试，质效合一